Using a Flowchart Simulator in a Introductory Programming Course

Right From the Start is a project at Western Kentucky University designed to provide novice students with a foundation for later programming study through a series of interactive design tasks involving fundamental logic structures. To support this goal, the instructional tool Visual has been developed and used in classroom settings. (To obtain copies of the Visual software and related support materials for academic use, visit http://cis1.wku.edu/visual ). Visual is an instructional tool designed for novice programmers and is intentionally easy to learn and use. When using this tool, students may design, develop, test and evaluate computer programs before introducing any traditional high -level language. This paper reports the results of an experimental design involving the use of Visual during the first five weeks of an introductory course. The results suggest instructional benefits for students who use interactive flowcharts to emphasize logic and design early in the first programming course. Introduction According to a recent National Academy of Sciences report, a number of essential elements are necessary for a person to achieve fluency with information technology (NAS, 1999). One of the essential elements identified in the report is exposure to computer programming. The report concludes that programming knowledge and experience is beneficial to everyone in an information society. “The continual use of abstract thinking in programming can guide and discipline one's approach to problems in a way that has value well beyond the information technology-programming setting. In essence, programming becomes a laboratory for discussing and developing valuable life skills, as well as one element of the foundation for learning about other subjects.” (NAS, 1999, p. 48). National Science Foundation (NSF) researchers suggest that programming instruction should not be limited to students in computer departments, noting that learning to program has been PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 2 shown to have benefits ranging from teaching general-purpose problem solving and thinking skills to helping students appreciate and understand how computers work (Soloway, 1993). Over two decades ago, MIT computer scientist Seymour Papert reported that a deep understanding of programming, in particular the design activity of successive decomposition as a mode of analysis and debugging of trial solutions, results in significant educational benefits in many domains of discourse, including those unrelated to computers and information technology per se. By transforming abstractions into concrete representations via programming, students "build their own intellectual structures with materials drawn from surrounding culture" (Papert, 1980, pp. 3132). While programming is considered a valuable learning activity, it is also a complex task and is often difficult for novices to master (Sleeman, 1986; Spohrer & Soloway, 1986; Malik, 2000). The following section provides an overview of previous attempts to improve the process of learning to program. This is followed by a report of two studies examining programming instruction using simple, intuitive flowcharts to abstract fundamental concepts that are foundational to all programming languages. Experimental investigations of the utility of flowcharts for novice programmers and the impact of a flowchart based learning tool on students understanding of fundamental programming activities are presented, followed by a general discussion of the results and its implications for educational technology. Prior Research on Programming as Design Advocates of programming as a learning activity are often not supportive of traditional programming courses which emphasize programming languages such as C++, Java, Visual Basic or Pascal (Saret, 2001; Sprankle, 1998). Rather, these advocates of programming as a learning activity emphasize the design process over the subtleties of syntax (Farrell, 1999; Kafai, 1995). PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 3 There have been numerous efforts to improve the programming process by minimizing the complexity of the syntax and increasing design activities (NAS, 1999; Robertson, 2000). The following section presents several examples of related studies that have received considerable attention and form the basis for this research project. Using Mini-Languages to Teach Novice Programmers One popular approach to teaching computer programming involves the use of minilanguages. The mini-language uses a programming environment with relatively few instructions/commands (e.g., Brusilovsky, Calabrese, Hvorecky, Kouchnirenko & Miller, 1997). Mini-languages are designed to be intuitive to novice programmers, allowing them to freely explore the problem-solving context without being burdened by syntax construction. These environments do not introduce any of the complex commands typically found in traditional highlevel languages. Instead, the programmer is provided with a set of basic commands that may be used to create simple solutions. One of the earliest examples of this approach was the Logo programming language as described in the book Mindstorms (Papert, 1980). Originally designed for children, Logo allows computer novices to create unusual geometric designs and cartoon drawings by controlling a programmable turtle with a small number of simple commands (e.g., “forward,” “back,” “left turn”). The Logo language has been well received for two decades, with various adaptations along the way. Another significant contribution to the simplified syntax effort was Karel the Robot (Pattis, 1981). It was designed specifically to provide “a gentle introduction to programming.” In 1996, Karel++ (Bergin et al., 1997) was developed to provide a similarly simple introduction to object-oriented programming. Logo, Karel, Karel++ and similar tools attempt to address the PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 4 design/syntax problem by making the design environment intuitive and the syntax simple. However, while reading the first programming chapter in Karel++, a novice is exposed to the following: punctuation rules, grammar rules, instructions, messages, classes, reserved words (e.g., void, task, class), special symbols, main task block, delimiters, declarations, error shutoff, lexical error, syntax error, execution error, intent error, and debugging. Some novices may disagree that this represents a “gentle introduction.” Iconic Programming An alternative to languages with a simplified syntax uses graphics instead of textual instructions. Calloni, Bagert, and Haiduk (1997) address the problem of minimizing syntactic detail though the use of BACCII, an iconic programming environment. All program constructs (including variables) are represented through icons. After the student builds a program solution using a logical series of appropriate icons, BACCII generates syntactically correct source code for the program in a traditional high-level programming language. The drawback is that the student must then compile the source code, execute and test it in the high-level language environment. Furthermore, all error messages and debugging requirements are communicated to the student using the syntax of the high level language rather than the familiar iconic representation. Pseudo Programming Another popular approach to programming instruction uses a procedural language, but relaxes the strict syntactical rules that often confuse students. Shackelford (1998) has developed an approach whereby novices use a pseudo language to develop their algorithms. The psuedolanguage allows students to write programs using common English words of their choosing. Pseudo-languages do not have to follow strict syntax rules making them easier to work with by PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 5 novices. Since the pseudo-language cannot be executed, students spend more time on designing a solution than dealing with implementation details. The limitation of this approach is the inability to actually execute the program results in a lack of real-time feedback to the student. The pseudo-language approach requires human evaluation for feedback, typically provided by the TAs or the instructor. There are also concerns regarding the consistency of human evaluations of pseudo-language solutions. The Utility of Flowcharts Supporters of programming in education are constantly looking for ways to emphasize the valuable learning activities of logic, design, problem solving, critical reflection, and selfexpression. A common goal of many computing educators is to somehow capture the essence of solution design without introducing the complexity of a high-level implementation language. One representational technique that has long been used to capture the essence of procedures is flowcharting. A flowchart is a diagram that shows step-by-step progression through a procedure. In computer programming, flowcharts allow a conceptual representation of important issues such as input, output, assignments, conditions, and loops. Some anecdotal data suggests that novice students perform better, faster and with more confidence when they examine designs represented as flowcharts rather than high-level language syntax. Apparently this observation is not unique, as the majority of introductory programming textbooks have traditionally used flowcharts when introducing important concepts. The potential value of flowcharts is further supported in the educational-psychology literature. Bloom’s Cognitive Taxonomy (Bloom, 1956) is a classification of levels of activities for human learning. Mastering the syntax of a traditional high level programming language primarily involves memorizing and recalling particular language details. Such activities are at Bloom’s lowest level PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 6 of learning. Flowcharts can be used to minimize the detail of language syntax while allowing students to work at a conceptual level—thereby supporting higher level learning activities. A number of studies have been conducted that examine the utility of flowcharts for various purposes and with various audiences (e.g., Higgins, 1987; Kammann, 1975; Ramsey, Atwood, & Van Doren, 1983; Scanlan, 1989; Shneiderman, 1975; Vessey & Weber, 1986; Wright & Reid, 1973). However, none of these studies compare flowcharts to language syntax with respect to novice programming students. The goal of these studies is to address this missing knowledge area, examining the utility of flowcharts for novice programmers for understanding computer algorithms. PROCEDURE Two experiments were conducted as part of the present study. The goal of the experiments is to examine the utility of flowcharts versus program code for novice students’ understanding of computer algorithms. Hypothesis 1.1: Novice programming students will develop more accurate program solutions using flowcharts than with structured code. Hypothesis 1.2: Novice programming students will develop program solutions more quickly using flowcharts than with structured code. Hypothesis 1.3: Novice programming students will have higher confidence in their program solutions using flowcharts than with structured code. Hypothesis 1.4: The benefits of flowcharts will be more pronounced as the problem algorithms become more complex. PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 7 Method Participants The participants for this study were 58 undergraduate students from two 100-level introductory Quick Basic (QBasic) programming courses. Both the instructors were computer science professors, and they used the same textbook, lesson plans, and pedagogy. Students in the courses came from different backgrounds and had different majors. There was an equal mix of males and females. Apparatus Using a methodology based on that of Scanlan (1989), the experiment required subjects to determine output solutions for three different problems—each more difficult than the last. Each problem had a flowchart representation and a Basic syntax representation. Each of the six representations was printed on a separate sheet of paper. Figures 1 3 show the flowchart and structured-coded representation of each problem. The contents of the flowchart symbols were a random placement of the same conditions and print statements as in the related program code. They are not reproduced in the figures due to size constraints. Each answer sheet contained three sets of values representing inputs to the computer program with corresponding space for the program output. Each answer sheet also contained a place for subjects to record the time when they finished from a digital clock clearly projected on a large screen throughout the experiment. Each answer sheet also contained space for subjects to identify how confident they were about their solutions. Insert Figure1 (Simple Problem) About Here Insert Figure 2 (Medium Problem) About Here PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 8 Insert Figure 3 (Complex Problem) About Here Procedure The experiment was conducted in the seventh week of the 3-hour course, approximately halfway through the course. Participants had been introduced to input, output, assignment and conditional statements, and flowcharts had been used in both classes to illustrate the semantics each statement type. The experiment took place during a regular class meeting time. Participants were randomly assigned an initial representation (either flowchart or structured code) for the “simple” problem along with a random answer sheet. Participants determined the output for each of the three program inputs provided on the answer sheet. After determining the three outputs for the problem, the subjects recorded the time as displayed on the projection screen. Finally, participants recorded their confidence level for their solutions on a 5-point scale (1 = not confident, 5 = very confident). All participants were given sufficient time to complete the task. Then subjects were given the alternate representation of the “simple” algorithm, a new answer sheet, and again determined the three problem outputs, recorded the overhead time, and rated their confidence in their solutions. This process was repeated for the two “medium” and two “complex” problems. Results The correctness score was determined by awarding one correctness point for each of the three outputs that was correct per solution sheet. The time data was recorded as the number of seconds required for determining the outputs for each given input. The confidence score was recorded PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 9 from the 5-point scale. This grading process was the same for each of the six answer sheets provided by each participant. Independent sample t-tests verified there were no differences attributed to teacher or method. Scores for correctness, confidence and time were then analyzed as paired-samples for significant differences. Hypothesis 1.1 suggests that novice programmers will generate more accurate solutions for computer problems represented as flowcharts than represented as structured program code. Support was provided for this hypothesis as participants’ flowchart-representation correctness scores were significantly higher (p <= 0.05) at each level, simple, medium and complex, as shown in Figure 4. Insert Figure 4 (Correctness Results) About Here Hypothesis 1.2 suggests that novice programmers will generate solutions faster when working with flowcharts rather than structured code. Participants’ completion times when using the flowchart representations were significantly lower (p <= 0.05) at each level, simple, medium and complex, as shown in Figure 5. Insert Figure 5 (Time to Completion Results) About Here Hypothesis 1.3 suggests that novice programmers will have higher confidence in their solutions when working with flowcharts rather than structured code. In support of this hypothesis, participants’ confidence ratings were significantly higher (p <= 0.05) for the flowchart representation than for the structured-code representation at each level, as shown in Figure 6. Insert Figure 6 About Here PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 10 Hypothesis 1.4 suggests that novice programmers will see an increased benefit when working from a flowchart representation versus a structured code representation as the complexity of the algorithms increases. In support of this hypothesis, the differences in scores between the two representations increased with complexity for each of the measurements (accuracy, time, and confidence, as shown in Figures 4-6). It is further interesting to note that the “complex” algorithm flowchart scores were better than the structured-code “simple” algorithm scores in all three measurements. Discussion The results of this experiment support the hypothesis that introductory programming students are better at processing computer algorithm-based problems represented as flowcharts rather than as a set of structured-code instructions. The study found significant benefits with respect to solution accuracy, time to completion, and subject confidence. When using the flowchart representation, participants made fewer errors, spent less time determining answers, had more confidence in their answers. The results also suggest that the observed benefits of flowcharts over structured-code increase as algorithm complexity increased. The Flowchart Interpreter The results of the first study clearly suggest that novice programming students benefit from a flowchart representation over structured code representation of the same problem. This experiment measured subjects’ ability to work through pre-defined algorithms and calculate solutions for given input data. The second experiment seeks to identify whether flowcharts provide similar benefit when subjects are asked to develop their own unique algorithms. PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 11 In addition to requiring subjects to develop program solutions in the traditional QBasic environment, a graphical CASE tool was used to support the construction of flowcharts. FLINT (Flowchart Interpreter) allows users to create flowcharts using the popular drag-and-drop approach common on tools such as ABC Flowcharter and VISIO. However, FLINT also provides a simulated interpretation of the flowchart in real-time. FLINT is an instructional tool designed specifically to provide user interaction with solution design activities. When using this tool, subjects may design, develop, test and evaluate computer programs without any need for a traditional high-level programming language. FLINT is designed for novice programmers and is intentionally easy to learn and use. FLINT avoids the complexity of a high level programming language by utilizing flowcharts to represent logical solutions. When using FLINT, subjects develop their solutions by adding, deleting and moving flowchart elements incrementally using a drag-and-drop interface. Figure 7 shows the flowchart design window with a single input, assignment, and output element. The contents of the flowchart elements may be edited by double-clicking on the element. Figure 8 shows the edit dialog window for an assignment statement. Insert Figure 7 (FLINT Flowchart Design Window) About Here Insert Figure 8 (FLINT Edit Dialog Box) About Here One of the most powerful features of FLINT is its ability to provide automated feedback of graphical (e.g., flowchart) designs. Users may evaluate their design by pressing the “EXECUTE” button. The flowchart solution behaves as a compiled implementation of a PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 12 traditional high-level language, pausing only for user-input commands. For debugging and pedagogical purposes, the user may execute the design one element at a time. This functionality is supported through the “STEP” button. Memory values (variables) change dynamically as each flowchart node is interpreted. Figure 9 shows the complete FLINT system interface. When the user is satisfied with the validity of the design, the flowchart may be printed and used as a model for the actual implementation. Insert Figure 9 (FLINT System Interface) About Here STUDY 2 The first study had no treatment group. The objective of the second experiment was to compare the end-of-semester effect of a flowcharting intensive treatment versus the traditional textbook approach. Hypothesis 2.1: The treatment group will develop a superior understanding of programming logic. Hypothesis 2.2: The treatment group will develop superior ability to write computer programs. Method Participants The subjects for this study were 73 undergraduate students at a comprehensive public university with a traditional 16-week semester. The courses were 200-level introductory Visual Basic (VB) programming taught by two professors. None of the subjects from the first experiment participated in the second experiment. Furthermore, the second experiment involved a different pair of professors. Students in the courses came from different backgrounds and had PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 13 different majors. Both instructors employed similar textbooks and course content except for the treatment. Subject assignment to class sections was semi-random as registration priority was done on the basis of last-name order. Apparatus The programming logic component of the experiment was again modeled after Scanlan (1989), involving three program output problems classified as “simple”, “medium”, and “complex”. However, there are two major differences from the first study. First, the problems were only presented in Visual Basic code representation. By design, treatment subjects used flowcharts at the beginning of the term. However, the experiment took place at the end of the term when all subjects, regardless of treatment, were expected to have developed proficiency with the Visual Basic language. The second difference from the first experiment is increased difficulty at each problem level. Specifically, looping constructs were included in this experiment (see Table 1). The increased difficulty was appropriate since the measurements were given at the end of the semester and the subjects were therefore presumably more proficient. Similar to the first study, answer sheets contained three sets of input values with corresponding space for the program output. Insert Table 1 About Here The solution design task involved writing a non-trivial computer program. Specifically, students were to write a program to function as a grade-book application (keep track of exam scores, calculate grades, etc.). This task was chosen because the context is well known to the subjects. A successful program solution to this problem would require the use of numerous PDF created with FinePrint pdfFactory trial version http://www.fineprint.com Flowchart Simulator 14 programming constructs presented throughout the course (e.g., assignments, conditions, iterations, complex calculations, accumulators, record processing, report generation). Procedure In the first experiment there was no treatment. In this experiment, students assigned to the treatment group exclusively used the FLINT instructional tool during the first five weeks of the course. Simple problem-solving activities using FLINT were assigned as homework. No VB instruction was provided during this time. Students assigned to control group were instructed in the traditional manner, beginning the first week with chapter 1 of the course textbook. After the first five weeks, the treatment group sections began using the same pedagogy and materials as the control group, beginning with chapter 1 of the textbook. Because the treatment group received exposure to key concepts (e.g., variables, conditions, loops, etc.) during the first five weeks using FLINT, they were able to cover textbook material more quickly, and they finished the semester covering the same textbook chapters as the control group. Therefore the difference between the treatment and control groups was a five-week introduction with FLINT followed by 11 weeks with the textbook for the treatment group versus 16 weeks with the textbook for the control group. The measurements occurred at the end of the semester during a regular class meeting (see Fig. 10). FIGURE 10 (Research Process) HERE